home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Aminet 1 (Walnut Creek)
/
Aminet - June 1993 [Walnut Creek].iso
/
aminet
/
gfx
/
show
/
gl1_3.lzh
/
gl.man
< prev
next >
Wrap
Text File
|
1991-06-19
|
10KB
|
241 lines
GL Documentation
Software:
GL
GLSplit
Pictor
Purpose:
To fiddle with GRASP animation files. These are found on PClones,
with the extension ".GL".
GRASP is a product of Microtex Industries, Inc.
Author:
John Bickers (JJB Templar) - jbickers@templar.actrix.gen.nz
Credits:
This was written using SAS C 5.10a.
The digital dissolve effect (fade 20) is from "
A Digital 'Dissolve'
Effect
", by Mike Morton, pg 221 of "Graphics Gems".
The format of a .GL file was obtained from the documentation file
for xgrasp, a Sun .GL player written by Patrick J. Naughton
(naughton@sun.com). This file included what appears to be documentation
from an early (Useware) version of GRASP.
The formula to convert from an RGB triple to a grayscale level is
from Usenet's comp.graphics FAQ.
Motivation is from MANDY-2.GL, which I saw running on a PS/2, and
which convinced me that perhaps PClone animations are worth
noticing.
Using GL:
This program is the .GL player. It has a number of limitations, which
include no font or text support, only two fades (0 and 20), etc.
The CLI usage is:
WSH 3> gl [-g] [-p] filename
The optional "-g" parameter tells GL to use a grayscale colormap for
the data. This is usually necessary for VGA animations, which have
256-color palettes. The original 256 colors are then mapped onto
16 gray levels. Note that this makes a number of GRASP color commands
and tricks useless, since the source data is converted into 4 bits
per pixel during the "cload" or "pload" commands, and cannot be
remapped to a new palette.
The optional [-p] parameter tells GL to use the picture offset
positions given in the .PIC files as their initial offset positions.
GL can only handle two of the many video modes a .GL may have. These
are CGA 640x200/1 ('C'), and VGA 320x200/8 ('L'). These happen to
be the only sample files available to me. I'd be happy to add more,
should the opportunity arise.
While GL is running, it is possible to send input to it. There
are two "input windows of opportunity". The 1st is at the end of
each command, when GL does a quick check of it's task signals. The
2nd is during the .GL "waitkey" command.
Window 1: no delay.
^C in the CLI you started GL from will kill it.
Esc will quit.
Space will go into pause mode.
Window 2: will delay until "waitkey" timeout occurs.
Esc will quit.
Space will go into pause mode.
Once in pause mode, a few key commands are available:
Space will leave pause mode, but reenters it at next window 2.
The 'S' key will save the current screen as an IFF ILBM.
The 'I' key will output some status info to the console.
Any other key leaves pause mode.
GL was written on an A2630. I've optimized some parts of the drawing
for VGA 'L' animations in assembler, but GL is still a little slow on
a 68000.
In my opinion, converting a .GL to something nice for the Amiga is
too much hassle to write a free program for (I don't know any
convenient Amiga formats, for example. ANIM option 5 is out). The
easiest approach is probably to extract the elements of the
animation, convert them to HAM if necessary, then put them back
together using an Amiga animation program.
People on Usenet have recommended Director 2.0(*) for this purpose,
though as far as I know no-one has tried it. Let me know if you
do (or if you can get format specs, and want me to take a shot at
writing an automatic converter).
(*) Note I have no affiliation with this program. I've never even
_seen_ it.
Using GLSplit:
This is like GRASP's "GLIB" program, but with extraction and listing
capabilities only. A .GL file is similar to an archive, and GLSplit
will allow one to extract any file one wishes.
The CLI usage is:
WSH 3> glsplit [-l] [-oprefix] [-xname] filename
If no options are specified, glsplit will extract all files from
"filename" into the current directory.
The optional "-l" parameter will produce a list of the files
within the .GL.
The optional "-o" parameter specifies a prefix for the output files.
For example, if one wanted to extract all files to ram:, one would
use:
WSH 3> glsplit -oram: filename
The optional "-x" parameter specifies that a particular file should
be extracted. For example, if one of the files in the .GL file happened
to be "main.txt", you could extract just that file with:
WSH 3> glsplit -xmain.txt filename
Using Pictor:
This program is intended to either display or convert PCPaint
picture files. These include the .PIC and .CLP files found in .GLs.
The same video modes are recognised as with GL - that is, Pictor
only knows how to handle CGA ('C') and VGA ('L') pictures. Again
similar to GL, Pictor displays 'L' mode pictures into a 4-bitplane
LORES screen.
The CLI usage is:
WSH 3> pictor [-vo] [-g] [-sname] [-lname] [-wname] filename
The optional "-v" parameter generates information from the header
of the picture. If an 'o' follows the 'v', then this is all the
processing that occurs (ie: [v]erbose [o]nly).
The optional "-g" parameter uses a grayscale colormap. HAM etc
conversion is better done with other tools, like HamLab(*).
The optional "-s" parameter tells Pictor to save the colormap of
the picture as a seperate file. The default name is "ram:savecolor",
and can be overridden by placing a filename directly after the "-s".
The purpose of this parameter is to provide .CLP (clip) pictures with
a colormap, since they do not usually have one. For example, if you
had two files "palette.pic" and "clip1.clp", you could display the
.clp file with:
WSH 3> pictor -s palette.pic
WSH 3> pictor -l -g clip1.clp ;or pictor -l -w clip1.clp
The optional "-l" parameter tells Pictor to load the colormap
for the picture from a file. The default name is the same as for
the "-s" parameter. This colormap can be used along with the
"-g" and "-w" options, either to display correct grayscales, or
to write out the correct colormap to the FIG workfile.
The optional "-w" parameter tells Pictor to write out the picture
as a workfile for my FIG(**) programs. The default name is
"ram:pictor.wrk". Older versions of the FIG software will not work
with these files, since I've added a two-byte identifier to the
workfile header in order to identify them to HamLab. I either use
FIG, or a filter that reads a workfile into HamLab, to process these
files.
(*) HamLab is an image conversion package written by Ed Hanway. The
package is shareware, though freely redistributable versions are
available. As of this writing, the version number is 1.1, and
Ed's email address is "jeh@sisd.kodak.com".
(**) FIG is an image conversion package written by me, before I
got HamLab. I still find it useful, since it only fiddles with 8-bit
data (therefore requires less space) and is script-driven.
Known problems:
Symptom: the right edge of a "clip" disappears from time to time.
This is a fault in the shifting routine not correctly handling
clips that overlap the left edge of the screen.
Symptom: parts of the picture are being drawn as black.
Some animations load "clip" data before they load "pic" data.
"clip" data does not usually contain color information, so when
the image data is converted to bitplane format, the result is
a blank clip, since the colors in the palette have not yet
been initialized.
To do:
Implement GRASP commands/video modes as required, I guess. No big
deal. As I get new animations, I'll implement basic stuff required
to play them.
More assembler.
Consistent operation across video modes and similar operations.
Dithering in the grayscale mode?
Change in the way things are done, to use the Blitter, double
buffer, etc?
Personal stuff:
Suggestions are welcome, and may even be implemented. I can be
contacted at the following:
Snail: John Bickers,
214 Rata St,
Naenae 6301,
New Zealand.
Email: jbickers@templar.actrix.gen.nz
Phone: 677-334, 672-085, or 746-625.
People who use this program are also invited to send some notification
of their existence to any of the above points. Feel free to pay
something (esp. if you want to request that something be added :) too,
but payment is not a requirement. I'd be more interested in
animations, actually (NOT NOT NOT via email! I have to pay $$ for
that!). Either Amiga disks, or MS-DOS disks up to 1.4M, are ok. The
nature of the animations is not a problem either. X-rated or clean
are both fine.
This program may be redistributed freely, but not for commercial gain
(ie: Fred Fish type costs are ok). Note that you should include the
documentation.
GL, GLSplit and Pictor are Copyright © 1991 by John Bickers.
History:
GL1.0 Began on 23rd Mar '91. Didn't do clips right.
GL1.1 Released. 68000 performance is slow and looks wavy.
GL1.2 Has some assembler optimization. 68000 copying performance is
ok. Still slower than it should be, but the waves appear to
be significantly reduced.
GL1.3 Added a variety of commands, transparency, offset positioning,
etc. Mostly motivated by animations received from David Yee.
Disclaimer:
"It works on my machine" (so far :).